As indicated back in December 2014, Infinispan provides a JSR-107 certified JCache implementation. Recently I caught up with Ben Evans from InfoQ to talk about Infinispan, the certification and other topics. You can find the interview here.

Cheers, Galder

The infinispan-jcache module in Infinispan 7.0.2.Final has been certified to be compatible JSR-107 1.0 specification implementation. To get started with Infinispan’s JSR-107 implementation, check the Infinispan documentation section on the topic, and remember that Infinispan also implements the JSR-107 annotations for CDI injection of cached values.

Thanks to everyone who has contributed to the module, and to Greg Luck and Brian Oliver for their help in completing the certification.

Cheers, Galder

Dear Infinispan community,

We’re pleased to announce the final release of Infinispan 6.0 "Infinium". As announced, this is the first Infinispan stable version to be released under the terms of Apache License v2.0.

This release brings some highly demanded features besides many stability enhancements and bug fixes:

For a complete list of features included in this release please refer to the release notes.

The user documentation for this release has been revamped and migrated to the new website - we think it looks much better and hope you’ll like it too!

This release has spread over a period of 5 months: a sustained effort from the core development team, QE team and our growing community - a BIG thanks to everybody involved! Please visit our downloads section to find the latest release. Also if you have any questions please check our forums, our mailing lists or ping us directly on IRC.

Cheers,

Adrian

The existing CacheLoader/CacheStore API has been around since Infinispan 4.0. In this release of Infinispan we’ve taken a major step forward in both simplifying the integration with persistence and opening the door for some pretty significant performance improvements.

The first ever JUDCon Brazil was held a couple of weeks back and it was a real blast! Firstly, it offered a great opportunity to meet some members of the JBoss community which have been helping us push JBoss projects forward in this region of the world, such as Hanneli Tavante, Roberto dos Santos Wagner, …​etc. It was great sharing ideas, experiences…​etc with them and coming up with new ideas!

As mentioned before in the post before the conference, I had two new presentations to deliver, one on JSR-107 specification on JCache API and Infinispan’s implementation, and the other on Hibernate Second Level Cache with Infinispan. The JCache presentation went really well and all the live coding worked as expected.

The second presentation was the busier of the two, with a full room packed with Hibernate/JPA users waiting to hear how to scale up their applications. I got excellent feedback from both presentations and looking forward to giving these presentations in more user groups or conferences.

The presentations are not up yet, but I expect them to be posted online in the next few weeks. In the mean time, here are a couple of temporary links to the PDFs of my presentations:

The big news of the conference was for sure the announcement of JBoss Application Servers' new name: WildFly. We’re actively working with them to make the most out of Infinispan :)

Cheers, Galder

As part of the recent Infinispan 5.3.0.Alpha1, the first Infinispan JCache implementation was released which implements version 0.6 of the JCache specification as defined by JSR-107. It passes 100% the mandatory TCK including optional transactions TCK.

A document on how to use Infinispan JCache implementation has just been released, which explains the basics of using JCache, how it differs with existing APIs provided by the JDK, and how to cluster JCache based cache instances. More information will be added to the document, including quickstarts, as we make further progress in the Infinispan 5.3 series.

Please note that the CDI and annotations part of JCache 0.6 specification is still in flux, and we’re not yet able to provide an implementation for it, but we expect the issues stopping the implementation to be resolved in the near future.

Finally, as it’s expected from first releases, some bugs might be present, so if you encounter any misbehaviour, check the list of issues associated with the JCache component to see if the issue has already been resolved, or if not, please report it so that it can be fixed ASAP :).

Cheers, Galder

Since version 5.0 (Pagoa) Infinispan has a new module. This module is a portable CDI extension which integrates Infinispan with the CDI programming model. Here are some highlights of what is provided:

Please note that this module is a technology preview and its API can still change. Next let’s discuss some of its details.

Typesafe injection and configuration of cache

The first feature you can use out of the box is the typesafe injection of the Cache and the CacheManager. Without any configuration you can inject the default cache, as well as the cache manager used by the extension. This injection can be performed in any bean managed by Java EE like EJB, Servlet and CDI beans. The only thing to do is to use the @Inject annotation:

Please note that the cache injection is typed. In this case, only String typed Java objects could be added as key and value.

It’s also possible to configure the injected cache using CDI. The first step is to create a CDI qualifier, and then create the cache configuration producer, annotated with @ConfigureCache. The qualifier is used to qualify the injection point and the cache configuration producer:

In the same way, a cache can be defined with the default configuration of the cache manager in use, using a producer field:

One advantage of this approach is that all cache configurations of the entire application can be gathered together into a single Configuration class.

The Infinispan CDI extension provides a cache manager with a default configuration (and it is used by default). You can also override the default configuration (used by the default cache manager), as well as the default cache manager. You can find more information here.

JCache annotations support

JCache (aka JSR-107) is famous as the oldest open JSR. However, this JSR has recently seen extensive progress, and is a candidate for inclusion in Java EE 7 (JSR-342).

This specification defines a standard caching API to work with a standalone cache, as well as a distributed cache. An interesting part of the specification are the annotations which are designed to solve common caching use cases. Some of the annotations defined by this specification are:

The following example illustrates the use of these annotations:

The Infinispan CDI extension adds support for these annotations. The only thing to do is to enable the CDI interceptors in your application beans.xml - you can find more information here.

Infinispan CDI and JBoss AS 7

With JBoss AS 7, you can setup an Infinispan cache manager in the server configuration file. This allows you to externalize your Infinispan configuration and also to lookup the cache manager from JNDI, normally with the @Resource annotation. This post has more details on the subject.

As we mentioned earlier, you can override the default cache manager used by the Infinispan CDI extension. To use a JBoss AS 7 configured cache, you need to use the cache manager defined in JBoss AS 7. You only need to annotate the default cache manager producer with @Resource. Simple!

Now, you can inject the cache defined in JBoss AS 7 as we described earlier.

What’s next?

Here is a highlight of the features you will see soon.

As usual you can open issues and features request on the Infinispan JIRA (component CDI Integration).

Feel free to open a topic in the Infinispan forum if you need help.

The Infinispan CDI documentation is here.

To see the Infinispan CDI extension in action you can browse and run the quickstart application here or watch this screencast.

Enjoy!

About the author   Kevin Pollet is a software engineer at SERLI a Consulting & Software Engineering company based in France. He’s an Open Source advocate and contributes on many projects such as Infinispan and Hibernate Validator, both at SERLI and at home. He is also involved in the Poitou-Charentes JUG and has spoken in many JUG events. He enjoys attending Java events like JUDCon, JBoss World and Devoxx.

I never got around to blogging about this when my talks were accepted for JavaOne this year, but it’s about time.

I have a conference session titled "https://oracleus.wingateweb.com/content/sessionDetail.do?SESSION_ID=23382[A Tale About Caching (JSR 107) and Data Grids (JSR 347) in Enterprise Java]" and a BoF session focused on JSR 347 titled "https://oracleus.wingateweb.com/content/sessionDetail.do?SESSION_ID=23380[Making Java EE Cloud-Friendly: JSR 347, Data Grids for the Java Platform]", which I will be delivering with fellow Infinispan developer, JBoss rockstar and overall nice guy Pete Muir.

Later on in the year, I will also be running a University talk at Devoxx in Antwerp, titled "http://www.devoxx.com/display/DV11/Real-world+deep-dive+into+Infinispan+-+the+open+source+data+grid+platform[A real-world deep-dive into Infinispan]".  This too will be with Pete and Mircea Markus, another core Infinispan developer.

This will be a great chance to learn more about Infinispan, data grids, JSR 107 and JSR 347, so if you are attending these conferences, make sure you add these talks to your agenda!  :-)

Cheers Manik

Exciting times; today the JCP voted in a new JSR that I have proposed, JSR 347: Data Grids for the Java platform.    I blogged about the original JSR proposal, and posted a follow-up to some criticisms around the proposal some weeks ago.  The proposal, however, went ahead, was assigned a number (347!) and has just been voted in by the JCP executive committee.

Before I go into the details of 347 and my plans around it, I’d like to highlight some concerns in the community, in the area of overlap with JSR 107.

Is JSR 107 dead? No.  In very recent months, there has been a flurry of activity in JSR 107.  Activity which I am a part of, and hope will drive 107 to completion.

Does JSR 107 compete with JSR 347? No.  JSR 347 aims to build upon JSR 107.  JSR 107’s goals is to provide a temporary caching API for the Java SE platform.  JSR 347 plans to reuse JSR 107’s APIs, adding additional features such as an asynchronous API, as well as defining mandatory characteristics such as behaviour with XA/JTA transactions and distributed workloads, thus targeting the Java EE platform.

Will JSR 347 retard the progress of JSR 107? No.  If anything, JSR 347’s need for JSR 107 to complete will add impetus to the JSR 107 effort.

I sincerely hope the existing expert group of JSR 107 (of which I am a member) can and will work well with (and join!) the nascent expert group of JSR 347, to drive both JSRs to successful completion.

Now onto next steps with JSR 347: forming an expert group to put together an early draft.  I would like to open invitations to join the expert group, please sign up on the JCP website.

With regards to process, with my background in open source and working with distributed teams, I intend this JSR to be developed in the public, making use of public mailing lists, public IRC channels and the like. I’ve even set up a twitter account for JSR 347 so people interested in its progress may follow it!

Cheers Manik

PCWorld has published an article on the recent data grid JSR that I have submitted.  As a follow-up to PCWorld’s article, I would like to make a few comments to clarify a few things.

I don’t quite understand what is meant by Red Hat’s approach not being the best solution.  Do people take issue with having a standard in the first place?  Or is it the standards body used in this particular case (the JCP)?  If it is the details of the standard itself, one should keep in mind that this has yet to be defined by an expert group!

It is unfortunate that the "others" mentioned in the article - who feel that Red Hat’s approach is not the best - were not able to provide any details about their objections. I would love to hear these objections and make sure that the JSR addresses them.

The importance of a standard, to remove vendor lock-in, etc., is pretty well understood, so I won’t go into too much detail here.  But with that in mind, I find Pandey’s comment regarding a "self-beneficial move" an odd one.  A standard makes it easier for people to switch between products (which may explain why no one else may have stepped up to the plate to propose such a standard thus far).  Proposing a standard makes it easier for end-users to move away from Infinispan.  Yes, it may help with awareness of Infinispan, but it also means Red Hat, just like other data grid vendors, will need to work really hard to make sure their products are up to scratch.  The only real beneficiary here is the end-user.  In fact, I’d like to invite Terracotta to participate in this JSR, as participation can only make it stronger, more relevant and eventually even more useful to end-users.

With regards to JSR-107, I believe Pandey has misunderstood the intention in proposing a data grid JSR.  I have proposed extending and building on top of JSR-107 - not throwing it away - and I have expressed this the JSR-107 expert group mailing list, of which Terracotta’s Greg Luck is a member.  In fact, without Pandey’s actually seeing my data grid proposal blog post - PCWorld’s article was written before I published details of the JSR submission, based on a high-level Red Hat press release - one has to wonder where such strong words come from!  :-)

Cheers Manik